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(54) Database relationship analysis and strategy implementation tool 



(57) The Database Relationship Analysis and Strat- 
egy Implementation Tool consists primarily of two sep- 
arate components, namely an Event Detective System 
and a Strategy Management System. The Event Detec- 
tive System creates an environment in which significant 
events within a data warehouse which create opportu- 
nities for the system user or the party of a data record 



can be detected, while the Strategy Management Sys- 
tem determines and operationalizes appropriate strate- 
gies on the basis of the detected events. The implemen- 
tation of the both these systems into a user environment 
provides the user with a consistent, systematic method- 
ology for defining, investigating and implementing ap- 
propriate actions, based on events which are specific to 
a party. 
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Description 

[0001] The present invention relates to an database 
relationship analysis and strategy implementation tool 
and in particular, to a database relationship analysis and 
strategy implementation tool which provides the meth- 
odobgy to detect significant events within a data ware- 
house and to operationalise the detection of events and 
the assignment of appropriate strategies. 
[0002] In many user environments, such as in retail 
and financial services, vast quantities of data is gener- 
ated every day through normal operation of the 
busimess which represents a potentially invaluable 
source of information to the user concerned. Even when 
this data is captured and maintained in a database, 
problems have arisen in the filtering out relevant infor- 
mation from the huge volumes of data within the data- 
base warehouse that is being constantly updated and 
in the analysis of the significance of this infornnation in 
the context of the user environment. In the retail and 
financial services environment.customers are tradition- 
ally treated in the context of a broad segmentation, each 
customer existing as a member of one or more seg- 
ments with a plurality of similar customers. Hence, if a 
retail or financial institution wishes to impart information 
to a particular category of customers, an appropriate da- 
tabase tool is used to extract a segment of customers 
which satisfy particular relevant criteria. 
[0003] For example, if a financial institutbn wishes to 
market a new investment product, the database tool 
may be used to extract all those customers having a cer- 
tain minimum balance in their account at that time. Other 
static demographic criteria may also be applied. Details 
of the new investment product are then mailed to those 
customers or they are contacted in some other way. This 
is a simplistic approach which makes minimal use of the 
data within the customer database and in general, the 
responsiveness of customers has been invariably low. 
This is largely because the information reaching many 
of the customers of the segment is of no relevance to 
them at that particular point in time even though they 
may share some attributes with customers who would 
be intersted in the product and because this approach 
does not take inti account the importance of timing level. 
The traditional database tool fails to take into account 
the history or circumstances of the individual customers 
of the segment and although all the individual customers 
will have had that minimum balance required in their ac- 
count at the time the segment is extracted, this does not 
necessarily mean that the customer is interested in buy- 
ing the product in question. 

[0004] In such environments, it is desirable that a 
more dynamic and individualistic approach be taken to 
database analysis and the subsequent actions of the us- 
er based on that analysis. A retail or financial institution 
requires regular monitoring of the details of customer 
records in its data warehouses on an individual basis so 
as to determine transactions, events and time frames 



which indicate the customer is in or is approaching a 
particular situation or is undergoing some change in cir- 
cumstances which may warrant some actbn on the part 
of the institution. In many cases it is believed that the 
5 task of undertaking such analysis and the initiation of an 
appropriate strategy for millions of customers every day- 
would be impossible or just too costly. Changes in the 
circumstances and behaviour of a customer presents a 
brief window of opportunity for the institution. To act on 
these opportunities, it is necessary to identify that a 
change in circumstances has occurred or is about to oc- 
cur, what that change in circumstances signifies and to 
instigate an appropriate action within a very short time 
span. For example, the fact that a customer moves to 
another employer in a different locality and has a signif- 
icant salary raise presents new requiements for the cus- 
tomer. The customer may be interested in purchasing a 
new house which is more convenient to his new place 
of work and so require a mortgage, in starting a retire- 
ment plan or due to the salary increase, the customer 
may be interested in investment in other savings plans, 
[0005] It is an object of the present invention to pro- 
vide a database relationship analysis and strategy im- 
plementation tool which can effectively leverage the 
vast amount of accessible data within the operational 
and application systems of a particular environment so 
as to offer enhanced understanding, interaction and 
communication opportunities. 

[0006] According to a first aspect of the present inven- 
tion, there is provided a method of contacting parties, 
characterized by the following steps: 

a) maintaining a vector management system, VMS; 

b) obtaining leads from the VMS which identify par- 
ties to be contacted; 

c) using the leads, making contact with parties; and 

d) imposing the following limits on the contacts: 

i) a maximum limit on the number of times each 
party is contacted during any given calendar 
period; and 

li) a minimum delay between one contact, and 
the next contact, of each party. 

[0007] According to a further aspect of the present in- 
ventbn there is provided a method of communicating 
with parties, characterized by the following steps: 

a) maintaining a database in which multiple data 
items are associated with each party; 

b) selecting a data item, monitoring it over time and 
identifying changes which occur in it; 

c) listing the pariies associated with the changed 
data item; 

d) dividing the listed parties into at least two groups; 

e) repeating steps (b) through (d) at least once, with 
respect to at least one other data item; 

f) contacting parties in the first group through a first 
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type of communication channel, subject to the fol- 
lowing limits: 

i) no party is contacted more than a predeter- 
mined number of times in any calendar period; 
and 

ii) after one contact of a given party, a subse- 
quent contact is not made until a predetermined 
interval has expired. 

[0008] According to another aspect of the present In- 
vention there is provided a method of communicating 
with parties, comprising the following steps: 

a) nr)aintaining a database in which 

I) a record is associated with each party, and 
ii) the records contain some common data 
Items; 

b) selecting a data item contained in multiple 
records; 

c) nrtonitoring the records containing the selected 
• data item; 

d) when changes occur in the selected data Item, 
selecting a strategy from a group of strategies, said 
group of strategies including different communica- 
tion tactics designed to influence behaviour of the 
parties; 

e) listing the parties associated with the changed 
data item; 

f ) dividing the listed parties into at least two groups; 

g) repeating steps (b) through (f) at least once, with 
respect to at least one other data item; 

h) contacting parties in the first group through a first 
type of communication channel, and contacting par- 
ties in the second group through a second type of 
communication channel; 

I) a maximum limit on the number of times each 
party is contacted during a calendar period; and 
il) a minimum delay between one contact, and 
the next contact, of each party 

[0009] An embodiment of the present invention will be 
described by way of example with reference to the ac- 
companying drawings in which:- 

Flgure 1 is a block diagram representation of the 
the architecture of a financial services environment 
Into which the database relationship analysis and 
declsioning tool of the present invention has been 
Integrated; and 

Figure 2 is a block diagram representation of a se- 
lection method of the present invention which de- 
scribes the leads and the process by which the 
leads are determined to be candidates for a partic- 
ular strategy. 



[0010] The database relatioriship analysis and strat- 
egy Implementation tool consists primarily of two sepa- 
rate components, namely an Event Detective System 
and a Strategy Management System. The Event Detec- 

s five System creates an environment in which significant 
"events' within a data warehouse which create "oppor- 
tunities' for the system user can be detected, while the 
Strategy Management System determines and opera- 
tlonalizes appropriate 'strategies' on the basis of the de- 

10 tected 'events'. The implementation of the both these 
systems into a user environment provides the user with 
a consistent, systematic methodology for defining, in- 
vestigating and implementing communications and oth- 
er actions, based on 'events' which are specific to a 

IS -party' 

[0011] A 'party' is any entity that can be identified 
from, and about whom informatbn is stored within the 
data warehouse. In the database of a financial institu- 
tion, the party will be a customer and may Include an 

20 individual, businesses, households or joint account 
holders. No party information is directly nnaintained with- 
in the Event Detective or Strategy Management System. 
The data warehouse may also contain infomnation (eg. 
information from a mailing list or obtained through mar- 

25 ket research) about parties that are not yet customers 
(prospects). 

[0012] An 'event' is an Identifiable occurrence within 
the record of a party which indicates to the user that it 
is an appropriate time for a certain action to be taken by 

30 the user in relation to that party. For example, in a finan- 
cial institution environment, the detected event may be 
that the customers salary is no longer being paid into 
his account which may indicate that the customer has 
been made unemployed. However, if this event is ac- 

35 companied by another event such as an amount of mon- 
ey is being paid into the account from a different source, 
this may Indicate that the customer has changed his job. 
[0013] An 'opportunity' is the possibility of generating 
value for the party and/or the user in the light of the de- 

40 tected event. In the above example, loss of employment 
may Indicate a potential risk in relation to the cutomer 
due to the loss in income and may warrant close moni- 
toring of the customer account or a direct communica- 
tion to the customer requesting confirmation of his sta- 

45 tus. Similarly, change of employer may warrant market- 
ing of certain new products to the customer as dis- 
cussed earlier. 

[0014] A 'strategy' is defined as an ongoing process 
that selects the parties (data records) in a data ware- 

so house that fit various profiles for the purpose of commu- 
nicating relevant information or taking some other 
course of action. In a financial services environment, the 
parties are customers of a bank or other financial insti- 
tution and the relevant information or action to be com- 

55 municated may concern any aspect of financial products 
or services, financial or legal advice regulatory require- 
ments or risk minimisation such as a credit block. 
[0015] The database relatbnship analysis and strat- 
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egy implementation tool allows a user to manage and 
control all strategies directed at the parties of the user's 
data warehouse by creating a list of strategy opportuni- 
ties, tailored for action by specific distribution channel 
classes. The tool albws for individually tailored strate- s 
gies and strategy process flows for each strategy oppor- 
tunity. If communications are made with a party» the re- 
sponses to activity are captured and then subsequent 
actions are determined by the party response (or lack 
thereof). io 
[0016] Figure 1 illustrates the architecture of a finan- 
cial services environment into which the database anal- 
ysis and decisioning tool has been integrated. The 
Event Detective System provides the methodology for 
determining the metrics required for selecting custom- is 
ers for certain types of actions or communications and 
results in recommended "calculations" that are stored in 
the data warehouse and are a component of a transac- 
tion update process. These 'calculations* may be used 
as selection variables for various actions operational- 20 
ized by the Strategy Management System. The Strategy 
Management System is an operational system that uses 
the customer centric data warehouse to select parties 
(I.e bank customers) that are suitable targets for various 
actions. The Strategy Management System must inter- 25 
face with the data warehouse from which it selects 
record subjects and with the Contact Management Sys- 
tem(s) of the financial institution, (eg.. call centre, mail, 
personal banker, etc.) in order to make the initial contact 
with, and to receive responses from the customers. The 30 
Event Detective System is independent of the Strategy 
Management System but is an important component of 
strategy control. 

[001 7] One of the goals of the Event Detective System 
is to track the life of an event through the detection proc- 3S 
ess, through implementation and then triggering of cus- 
tomers so as to analyse the usefulness of the process. 
[0018] In addition to the marketing and risk manage- 
ment opportunities discussed above, other areas in a 
financial services environment where customer 40 
"events' may be relevant include customer profitability, 
customer satisfactbn or dissatisfaction or any other as- 
pect of the bank/customer relationship. The proce ss 
could be used very effectively for immediately identify - 
jng changes in the credit status of a party and for mon- 4S 
Itoring delinquen t accounts. If the event detective meth- 
~ odok>gy and proc ess are impiementeci appropriately it 
^may be able to id erinf y a change I n I I lu ri sk p TStiie of the 
custom er at the earliest possible stage and take appro- 
priate action bv freezing the credit facility before It be-_ so 
comes a high credit risk for the bank or a major problem 
Jorjhejcustomer 

[0019] The structure and operation of the Event De- 
tective System will now be described in detail. 
[0020] The Event Detective System provides the ss 
methodology and the application for defining customer 
'events' which can be replicated through a systematic 
approach. The Event Detection methodology uses 



^specified operating rules and p arameters for timely 
identification of significant events where si g nificance is, 
defined in the context of p revious behaviour of the Indi- 
vjdual-Cu$tQmer_rather,than_average^Qr_ty pical beha v^ 
l our for a particular product or servi ce. In addition to the 
events discussed above, other e xamples of events in -^ 
elude a change of address, a significant account bal- 

^ ance change, large transactions, a change of transac- 
tion volu me, an opening or closing of an account, a sal- 
ary payment start or stop, the starting or cancelling of _ 
standing instructions, pay -off balance inquiries, termi- 
nation"of loan s or leases, an overdraft, maturing of term 
deposits, a change In the location at which transactions 
are conducted. These events may be identified through 
transactions or communications that may precede or ac- 
company a change in the party's (I.e customer's) finan- 
cial^requirementg^orop portunities and may be used in- 
dividually, or Irt combination to identify that contact with 
the party may be warran ted. Events may also be indi- 

. cators Telated to satlsfactk>n with the financial institu- 
tion, interest in competitive offers etc. 
[0021] Event detectives are a sequence of scripts that 
are executed against the data warehouse at regular in- 
tervals, typically daily. The purpose of these scripts is to 
find significant events that have occurred specific to a 
party that may be of interest. An event detective is the 
process of combining data sources and operating rules 
in such a way as to encf up with a set of event triggers 
that can be actioned by other operating processes. 
[0022] The event detectbn methodology Is supported 
by an application that leverages parallel processing ca- 
pabilities in knowledge, discovery and data mining. The 
combination of the event detection methodology with 
ongoing data mining provides the basis for a learning 
environment that will grow in sophistication through ex- 
perience, testing and improving rules and methods 
through time. This allows the financial institution to dy- 
namically build individual customer models and identify 
changes to a record subject's profile through time. In 
other words, the Event Detective System provides a 
modelling methodology that supports a unique and dif- 
ferentiated level of observation, dialogue and respon- 
siveness. The event detectives may also provide input 
for other processes such as strategies and models but 
are not strategies or models in themselves. A history of 
the event detective investigations is maintained in order 
to leverage the learnings from the hypotheses that are 
tested and tofaciltate the incorporation of existing event 
detectives and their components into future event de- 
tectives. 

[0023] Any table in the customer focussed data ware- 
house can be used as a data source for an event detec- 
tive, including the tables of event triggers from other 
event detectives le. the result of one event detective can 
be used as input to another event detective. For exam- 
ple, there may be two event detectives in place - a salary 
start detective and the other a salary stop detective. If 
there is a need to find those occasions where a salary 



4 



7 



EP 0 919 942 A2 



8 



start and a salary stop occur, then the salary start de- 
tective and the salary stop detective can be used as data 
sources for the salary start and stop detective. Other da- 
ta sources may include the 'normal' data warehouse ta- 
bles like daily transaction and customer tables and sum- 
mary tables that include data like average balance, min- 
imum deposit etc. As a rule, if the data is in the data 
warehouse, then it can be used as a data source tor an 
event detective. 

[0024] A specified operating rule is the logic that de- 
fines part of the criteria for an event detective and in- 
cludes the criteria for the detection of the event suspects 
as well as the criteria for evaluating the significance of 
the event for the associated record subject. For exam- 
ple, if an event detective is defined to detect significant 
large deposits, then a possible operating rule to detect 
the event suspects might be that there is a deposit of at 
least $15,000. To then evaluate the significance of the 
deposit there are may possible operating rules that can 
be used, either in isolation or in combination. Examples 
Include that the amount of the deposit is greater than 
the previous maximum deposit, that the deposit is 30% 
greater than the average monthly deposit for the last 6 
months, that the deposit Is more than 1 .5 standard de- 
viations above the average deposit, that there is no with- 
drawal that matches the amount of the deposit, that the 
deposit is not a balance pay out for a loan, that no de- 
posit of a similar magnitude has occurred within the last 
1 2 months or that the deposit is not into a term deposit 
account etc. 

[0025] Each operating rule uses parameters that 
qualify the rule. In the above example, the initial busi- 
ness rule had a parameter that the deposit value must 
be greater than $15, 000, while the other operating rules 
had parameters like standard deviation greater than 1 .5, 
no previous deposit within 12 months. Some operating 
rules may use more than one parameter, and likewise, 
a parameter can be used by more than one operating 
rule. However, a parameter only has an affect on the 
operating rules within one event detective. 
[0026] Many of the operating rules within an event de- 
tective do not create a list of event triggers. In fact, only 
one operating rule per event detective does create a list 
of event triggers. Operating rules both act on a data 
source to define a list of event suspects, and then act 
on the list of event suspects to successively fitter the 
event suspects down to a list of event triggers. Each op- 
erating rule that creates a list of event suspects or fil- 
tered event suspects stores its result set in a temporary 
table. 

[0027] The temporary table is only accessible within 
the event detective that defines it. This means that no 
other process (including other event detectives) can use 
the temporary table as a data source. The table is only 
populated for as long as it takes to run the event detec- 
tive that it is associated with. If the deductive method of 
another event detective finds that the temporary table is 
useful, then the user must define a new event detective 



that does the part of the process up to populating the 
temporary table required, and then redefine the original 
event to use the new event detective as a data source. 
This has no material impact on the outcome of the orig- 
s inal event detective, but does maximise the reusability 
of processing that occurs. 

[0028] The pool of events (with the associated party) 
that are the result of the execution of the event detec- 
tives are the event triggers. The event triggers include 

10 all infonnation about the record subject and the event 
being detected that may be required for other operating 
processes or modelling activities.The event detectton 
methodology does not nnake any judgement about the 
usefulness of the detection of the event at all. The use- 

15 fulness of the detected event is determined by the fact 
that another operating process accesses the event trig- 
gers. The list of event triggers is the event pool which Is 
simply the pool of results that is the outcome of the event 
detection process. The event triggers are actually con- 

20 tained within a table in the record subject focussed data 
warehouse. Each event detective has its own table. Oth- 
er event detectives can use the event pool as a data 
source for their own purpose. 

[0029] The event process is the combination of data 
25 sources, operating rules, temporary tables and event 
triggers combined in an appropriate manner to define 
the event detective specified In the definition phase. An 
event detective Is implemented by the event process. 
The success or otherwise of the event detective is gov- 
30 erned by the appropriateness of the event process being 
used. 

[0030] There are four major functional components 
within the Event Detection Methodology: 

35 Event Definition 

Event Investigation 
Event Resolution 

Event Trigger Tracking and Reporting 

40 Each component is broken down into activities , each ac- 
tivity having a set of related tasks. A task has associated 
documents which could include inten^iew results, find- 
ings of the analysis (both successful and unsuccessful), 
forecast statements and results. Some tasks will also 
45 have associated scripts which are the pieces of process- 
ing logic (SQL queries and Multiload jobs for example) 
that actually detect the event. 

[0031] Event Definition is targeted at the systematic 
identification and validation of events, activities or trans- 
50 actions that may precede or accompany a targeted op- 
portunity. These events, activities or transactions may 
be defined through knowledge of the environment, ex- 
perience or data mining. This Event Definition is the' in- 
frastructure for maintaining the documentation of as- 
55 sumptions, selection criteria, operating rules and fore- 
casts for the events that may identify an opportunity that 
has been determined through an information gathering 
process. This component includes templates for speci- 
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fication of parameters (including what parameters to use 
and how to use them), recommended tables for initial 
implementation, operating environment and a method 
for tracking and validating the effectiveness of the de- 
fined events in identifying actionable opportunities 
through interaction with other tools. 
[0032] The Event Investigation component builds the 
process that the event detective will use in order to de- 
tect event suspects and validate that the event is signif- 
icant for a particular party (i.e customer of the financial 
institution). An event is validated as a significant event 
based on history, seasonal or cyclic patterns etc. for this 
specific record subject (i.e. it is the process of comparing 
the event to the operating rules defined in the pre-proc- 
essed record profile). A validated significant event is no 
longer an event suspect, it is an event trigger. There are 
two ways that an event may be created, both of which 
are supported by the application. One method is an in- 
ductive method which builds from a process to a 
premise and the other is a deductive method which 
builds from a premise to a process. For example, an in- 
ductive method would start with a process like - find all 
occasions where a salary payment start occurs within 
1 5 days of a salary payment stop, and then try to attach 
an operating value premise to the result. A deductive 
method would start with an operating value premise like 
- it is probably useful to be able to detect those records 
which indicate that a new job has been started, and then 
try to attach a process to the premise. In reality most 
event detection will be a combination of the two meth- 
ods. The deductive method relies on the ability to reuse 
processes and tables from other event detectives that 
have been created. 

[0033] The inductive method comprises the activities 
by which the process of detection for the new event de- 
tective is built. It combines data sources and operating 
rules in a way that results in the desired event triggers 
being detected. Invariably, part of the inductive method 
will involve comparing the event suspect with the asso- 
ciated party profile in order to determine the significance 
of the event. For example, in order to determine whether 
a deposit of greater than $1 0,000 is significant for a par- 
ticular record, it may be compared to the previous max- 
imum deposit made. The previous maximum deposit 
would have been pre-calculated to allow for simple 
processing during event detection. 
[0034] The deductive method leverages off the work 
that others have done previously in order to determine 
what other parties have been found of a similar nature. 
For example, consider a premise that it is important and 
useful to find those parties who have started a new job. 
The following concepts may indicate a new job; a salary 
change, the fact that there was an old job, an employer 
change, a deposit change (e.g. change of source, 
change in amount, change in frequency of payment or 
a change in location), a change in the most popular au- 
tomated teller machine (ATM) usage between Sam and 
6pm on weekdays and a change in bank branch usage. 



[0035] By searching the existing event detectives for 
others that use the same concepts, the user may get an 
understanding of how other users have approached 
similar tasks, or in fact, find that the event detective re- 
5 quired has been created previously. The deductive 
method will most often result in the inductive method 
taking place. 

[0036] The event detective methodology has a task to 
explore the reuse potential that exists in other event de- 
tectives, thereby supporting the deductive thought proc- 
ess. The methodology ensures that the experience of 
defining events is captured and able to be reused both 
within and between operating environment sites. It also 
introduces rigour to the event detection and data mining 
process. 

[0037] Regardless of how the user approaches the 
event detective creatbn. there is a need to actually build 
a process for event detection. 

[0038] The Event Resolution component addresses 
the resolution phase of the event detective. The resolu- 
tion may range from the event detective proving not to 
be valuable enough to detect through to the event de- 
tective being extremely valuable to the operating envi- 
ronment (i.e the financial institution), and so must be im- 
plemented into the environment as soon as possible. 
[0039] The Event Trigger Tracking and Reporting 
component ensures that adequate information is cap- 
tured within the system to allow appropriate manage- 
ment reports to be generated. 

[0040] The structure and operation of the Strategy 
Management System will now be described in detail, 
[0041] The Strategy Management System selects 
parties from a list of all parties who meet a set of criteria 
and passes the leads to channel instances who then 
make contact with the data subjects and manage the 
responses therefrom. The Strategy Management Sys- 
tem requires the data entities within both a Lead Man- 
agement and a Lead Definition database and these are 
either replicated or integrated with the data warehouse. 
In the Lead Management database, the tables LEADS, 
LEAD_HISTORY, STRATEGIES, COMPLAINTS. 
MORE_l NFO_REQUESTS and 
UNREALISED_OPPORTUNITIES in particular must be 
included in the data warehouse as they all describe the 
management of the relationship with the party 
[0042] The Strategy Management System is a lead 
definition, generation, allocation and response nnanage- 
ment application. In a financial services environment, it 
supports a bank-wide integrated approach to the plan- 
ning and offers unique capabilities for rapid identification 
of customer opportunities and effective deployment of 
the bank's communication strategies to address those 
opportunities. The system provides a flexible platform 
designed to support high volumes of concurrent strate- 
gies across multiple channel classes. 
[0043] A strategy may be a communications tactic 
that will be used to contact the customer with a particular 
objective in mind or some other action to be taken by 
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the user The components of a strategy a selection 
method, the frequency of execution, the duration of the 
strategy etc. For each strategy, the class of the strategy 
(eg. Risk, Event, Information, Activation, Prospect etc) 
and/or limits regarding the frequency or the volume of 
contact (eg. do not contact a customer nrKtre than 8 
times per year or within 30 days of last strategy) are de- 
fined. Strategy classes may also be subclassed to more 
finely define and group strategies or leads. A cell is de- 
fined as a random set of the strategy leads. A strategy 
must have at least one cell, but may have more than 
one. If a strategy includes more than one cell, then there 
is something different about the way each subset of 
leads is managed within the strategy (eg. the channel 
class used, the offer or the collateral used within the 
channel class etc.) A cell is not differentiated from other 
cells because of the segment being addressed since 
segment type information is managed by the selection 
method 

[0044] The Strategy Management System consists of 
seven major functional components: 

Lead Definition 
Lead Generation 
Lead Allocation 
Lead Management 
Response Management 
Reporting and Tracking 
Utilities and Housekeeping 

[0045] The Lead Definition component provides the 
infrastructure for maintaining the documentation of as- 
sumptions, selection criteria and forecasts for the leads 
generated for targeted communications and incorpo- 
rates the interface of research, design and prototyjaing. 
[0046] The Lead Generation component cooperates 
with the database administrator for the extraction of cus- 
tomer information from the party focussed data ware- 
house, for replication Into the lead management data- 
base. This component builds and runs the selections. 
[0047] The Lead Application component works side 
by side with the Lead Generation component and focus- 
es on allocating the generated leads to the nominated 
communication channel classes. This component per- 
forms party, channel instance and strategy limiting and 
loads the leads into the lead management database for 
distribution to a Contact Management System(s). 
[0048] The Lead Management component performs 
the maintenance of the leads, including lead table up- 
dates, lead history table updates, step update files, time 
out leads etc. 

[0049] The Response Management Component ob- 
tains responses from the Contact Management System 
(s), including expected responses, requests for informa- 
tion and complaints. The Response Management func- 
tion will include a capability for the manual and automat- 
ed entry of customer responses to allow for the high var- 
iability of response capture across banks, as well as 



within each Contact Management System. 
[0050] The Reporting and Tracking component pro- 
vides the ability to perform tracking and reporting of 
strategy classes, strategy sub-classes, strategies, cells, 

s steps, responses (including complaints and requests for 
more information) and leads (including unrealised op- 
portunities and control group leads), including the sta- 
tus, performance and disposition of leads. The Strategy 
Management interface does not provide the presenta- 

10 tion layer for any reporting requirements but ensures 
that adequate information is captured and maintained 
within the system to allow appropriate reports to be gen- 
erated by other tools. 

[0051] The Utilities and Housekeeping component 

IS manages the regular housekeeping tasks that need to 
be conducted to keep the application manageable and 
relevant. These tasks are not operational tasks and in- 
clude the archiving of old Leads, Control Groups and 
Unrealised Opportunities. Utilities are one time or repeat 

20 processes to perform specific adhoc activities in initial 
set-up of a system (e.g. Response Actbns Creation ) 
and to refresh the system as required. 
[0052] A selection method is the query that runs 
against the database to select leads for a strategy and 

2S comprises three main components - the scoping varia- 
bles, the lead identifier and the selection variables. 
[0053] Scoping variables are essentially the WHERE 
clause of the SQL used to generate leads and may be 
stored data within the database, or derived from data 

30 stored within the database. The application of the scop- 
ing variables effectively defines the segment that the 
strategy is targeting and defines the qualification criteria 
that a customer must meet to be selected within the 
strategy. Each customer that meets the criteria will be- 

35 come a record in the strategy and each record that Is 
part of the result set is a lead database. There is no limit 
to the number of scoping variables In a selection meth- 
od. 

[0054] The lead must be uniquely identified across all 

40 strategies and all strategy iterations. This unique key 
would typically be the PARTYJD PARTY_TYPE, 
STRATEGYJD and SELECT10N_DATE. The data ele- 
ments that are selected for the lead are called selection 
variables and are the variables that are used to describe 

4S desirable attributes of the lead for the purposes of the 
strategy. Like scoping variables, they may be stored or 
derived values. The scoping variables used do not need 
to be included in the selection variables, nor do the se- 
lection variables need to be included in the scoping var- 

50 iables. However, the scoping variables are commonly 
included in the selection variable set. The selection var- 
iable values may provide useful background information 
and context for the channel instance making the contact 
with the customer to help identify why this customer was 

55 considered to be a candidate for this strategy. The 
number of selection variables per selection method is 
set to a predetermined maximum (e.g. ten) which means 
that it may not be possible to include every scoping var- 
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table in the selection variable set. The selection varia- 
bles cio not have to include contact information (i.e any 
information that needs to be provided to actually make 
the contact with the customer, as well as any back- 
ground information on the customer that may be useful 
to the channel instance). For example, if a lead is to be 
directed to a personal banker then the contact informa- 
tion would Include the name and phone number of the 
customer to be contacted as well as relevant account 
information. The contact information is determined at 
the time of delivering the lead to the channel instance 
by joining the lead to the customer table rather than as 
part of the selection method. However, if some aspect 
of the contact details are to be used as a scoping vari- 
able (eg. Customer Address falls within post code x) 
then rt may be part of the selection variable set so as to 
highlight to the channel instance making the contact why 
the customer was selected for this strategy. Any infor- 
mation within the data warehouse may be passed to the 
channel instance if it is deemed important. 
[0055] The combination of scoping variables, selec- 
tion variables and leads makes the selection method 
which describes the leads and the process by which the 
leads were determined to be candidates for the strategy. 
Each strategy has one and only one selection method 
but a select k)n method may be used in more than one 
strategy. On defining a strategy, the scoping variables 
and the selection variables that comprise the selection 
method for the strategy are defined. This is the decision 
as to what data elements will be important to provide 
context and description of the lead to all channel class- 
es. 

[0056] Referring to the selection method represented 
in Figure 2, the data element INCOME is used as both 
a scoping variable and a selection variable. The actual 
value of INCOME (eg. $75,320 per annum) is quite pos- 
sibly irrelevant to the channel instance without the con- 
text of the relevant range ie. that it is greater than 70000. 
This implies that there is a requirement to provide the 
selectbn method to the channel class, in combination 
with the selection variable values generated for the lead. 
[0057] Selection variables may also be used for the 
allocation of leads to different cells within a strategy. As 
an example, consider a strategy with two cells, each cell 
using a different channel class - one personal banker, 
and the other call center. The allocation of a lead to each 
cell may be based on the value of the selection variable 
INCOME. INCOME as a scoping variable is limiting 
leads to those with values greater than 70000, but as 
part of the definition of the strategy all leads with an IN- 
COME greater than 120000 are to be to the personal 
banker cell, while all others (INCOME between 70000 
and 120000) are to be allocated to the call center cell. 
This requires the creation of two very similar strategies 
where the selection method differs only by the applica- 
tion of the scoping variable INCOME. One strategy 
would limit leads to those with INCOME values between 
70000 and 120000, while the other strategy would limit 



leads to those with INCOME values greater than 
120000. Only one strategy with the appropriate selec- 
tion method need be developed, and then the strategy 
copied and the selection method changed. 
s [0058] Leads are allocated to cells based on a simple 
random algorithm (a variation of the Monte Carlo algo- 
rithm) which randomly allocates leads to cells on a 
weighted basis. 

[0059] Each component process of the strategy is 
called a step and each step is associated with a channel 
class, messages, responses and actions. An action will 
indicate what the next step of the strategy is for the lead 
being act ioned. Some actions can be automated by hav- 
ing a time based event (or time out) associated with the 
action ( eg. automated transfer of a lead to the call center 
channel class five days after the maW out has been sent). 
The channel class designates the class of communica- 
tion to be implemented for the step (eg. mail, personal 
banker, call Center, automated teller machine (ATM) 
etc.). Each step can have only one channel class asso- 
ciated with it. The channel class instance is the actual 
means of making contact with a customer (eg. name of 
the personal banker, work-station within the call center, 
ATM number etc.). 

[0060] The lead being nnanaged within a strategy are 
the result of the application of the selection method for 
the strategy and are the unique identification of a cus- 
tomer within a strategy. There are two exceptions to the 
selection method that change the way in which leads 
may or may not become part of the strategy. The first 
exception is a seed list for inclusion in various steps of 
a strategy. This is a list of individuals or entities that will 
be included in the execution of a step of a strategy re- 
gardless of the selection method and any limiting (either 
by customer or by channel class). A typical use of a seed 
list is as a list of employees that are included in a step 
of a strategy to ensure that contact call centers or mail 
centers are actually making the contact. Multiple seed 
lists (per channel class, per strategy class etc) may be 
provided. The second exception to the selection method 
is an exclusion list (i.e a list of customers that have re- 
quested that they not be contacted and so must not be 
included in the strategy). An exclusion list would typical- 
ly contain the customer identifiers of those customers 
who had requested that they not be sent unsolicited pro- 
motional mail. The use of the exclusion list is made at 
every iteration of the strategy and before any limiting 
has occurred. It is used at the lead generation time, and 
also each time a lead is stepped within the strategy so 
as to ensure that if a customer contacts the bank inde- 
pendently of the strategy and asks not to be contacted, 
then that customer should not be contacted for strate- 
gies already running. 

[0061] There are three types of leads that can be as- 
sociated with a strategy : active leads, unrealised op- 
portunities and control group leads. 
[0062] Active leads are those that have successfully 
passed through a customer limiting process and are be- 
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ing managed within a channel class, depending on the 
step within the strategy the lead is currently in. 
[0063] An unrealised opportunity is either a lead that 
has not been allocated to a channel instance as a result 
of the limiting process or a lead that has timed out and 
been sent to an unrealised opportunity list. Reasons tor 
unrealised leads may be that contact for this strategy is 
too close to a previous strategy, that there have been 
too many contacts with this customer in the last 12 
months, that the customer was selected tor more than 
one strategy today that the channel instance that this 
lead was directed to had too many leads, that too many 
leads were generated for this strategy today that the 
channel instance that this lead was directed to was on 
hold or that the channel instance that this lead was di- 
rected to was closed. The lead identifier 
(STRATEGY_NO. CUSTOMER_NO, 
CUSTOMER_TYPE, SELECTION_DATE) and the 
REASON that the lead was unrealised are recorded, 
along with the selection variable values for the lead. The 
reason for capturing unrealised opportunities separately 
is to gain visibility of those customers that meet the se- 
lection criteria for a strategy but for some reason are 
unable to be appropriately managed within the strategy. 
In those cases where the channel instance is unable to 
accept the lead, the lead may be cascaded to an alter- 
native channel class, typically a channel class with 
much larger capacity instead of sending the lead to the 
unrealised opportunity table. For example, if a lead was 
selected in a strategy, and the strategy tries to allocate 
the lead to a personal banker, but the personal banker 
is at capacity, a decision must be made as to whether it 
is useful to redirect the lead to the call centre or mail 
where the lead may not get the attention it deserves or 
to redirect the lead to the unrealised opportunities table. 
Directing a lead to the unrealised opportunities table al- 
lows the cause of leads not being action ed in the way 
the strategy Intended to be analysed. By this analysis it 
may be found that the personal banker channel class is 
under staffed. It may even be possible to define a strat- 
egy that uses the unrealised opportunities table as its 
data source, thereby reconsidering those leads that 
failed to be actioned in the original strategy. 
[0064] A lead cannot become unrealised through a 
positive action on behalf of a channel instance but only 
through the limiting process or the fact that the lead has 
timed out within the step (considered a passive action). 
This means that every action that a channel instance 
can make on the lead must be a positive action resulting 
in a known status. 

[0065] A reconsideration process for unrealised op- 
portunities is carried out at subsequent iterations of the 
strategy and the rules that re-consider unrealised op- 
portunities may be different for each reason that the lead 
became unrealised. For example, if the lead became un- 
realised because the volume of contact was too high for 
the customer within the last twelve months, then the lead 
should probably not be re-considered at the next itera- 



tion. However, if the lead became unrealised because 
of the limit on the number of leads generated each day 
then the lead should be re-considered at the next itera- 
tion. 

s [0066] Control group leads within a strategy allow the 
use of a control group of customers to help ascertain the 
effectiveness of the strategy. The method of using con- 
trol groups ensures that the control group is not contact- 
ed for any strategy whatsoever, thus allowing the true 
impact of the strategy to be judged. However, the meth- 
od does not ensure that any customers will be selected 
for the strategy that are also members of the control 
group. This means that it may not be possible to com- 
pare control group leads with active leads when trying 
to determine effectiveness. If a subset of customers that 
qualify for the strategy as a control group is to be used, 
then a cell of the strategy may be implemented as the 
control group. This allows more accurate analysis of the 
effectiveness of the strategy amongst potential targets, 
but does not ensure that no other strategy contacts the 
customer. 

[0067] The Strategy Management Tool is capable of 
applying limits to the allocation of leads within a strategy. 
Limiting is designed to achieve three things: to ensure 
that the customer is not over contacted, to ensure that 
channel Instances do not have so many leads allocated 
to them so as to exceed the capacity of the channel in- 
stances, and to ensure that the strategy budget is not 
exceeded because too many leads are generated. If, as 
a result of limiting, the lead can not be allocated to the 
intended channel instance, the lead may be assigned to 
the unrealised opportunities table or the lead may cas- 
cade from the intended primary channel class to a sec- 
ondary overflow channel class. 
[0068] Three categories of limiting are possible: cus- 
tomer limiting, strategy limiting and channel instance 
limiting. The order in which these limits are applied has 
no bearing on the result but will affect the amount of 
processing that has to be done. The following order of 
application is desirable: 

1 . customer volume limiting and customer recency 
limiting occur concurrently; 

2. strategy iteration limit, strategy total limit, channel 
instance new leads limit, channel instance out- 
standing leads limit, strategy cascade channel in- 
stance new leads limit and strategy cascade chan- 
nel instance outstanding leads limit occur concur- 
rently 

[0069] After customer limits have been applied, there 
is a list of leads that are sorted in some order, even if 
the order is arbitrary. The strategy limits and channel 
instance limits apply to the set of customer limited leads 
such that the first leads in the list are tested against the 
strategy and channel instance limits first. This means 
that the first lead in the list will have the best chance of 
being allocated to a channel Instance. For example, if 
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after customer limiting is applied there are 2,000 leads 
still able to be allocated, but there is a limit of 1 ,500 leads 
generated per strategy cycle, then the first 1 ,500 leads 
are the ones that get past the strategy limiting, not an 
arbitrary 1,500. If no lead is more important than any 
other lead within the strategy, then the selection method 
does not need to use an order, so the first leads are es- 
sentially randomly selected. 

[0070] There are two types of limits that can apply to 
customers, a recency limit and a volume limit. The re- 
cency of contact limit is defined at the strategy class lev- 
el and applied to the customer level while the volume of 
contact limit is defined at a system level. On defining a 
strategy, the use of customer limits defined in the system 
may be overridden (ie. customer limiting will not be tak- 
en into consideration when generating leads for the 
strategy). The option to override customer limiting can 
be set at a strategy class, strategy sub-class, channel 
class, strategy levels and customer segment. However, 
It is not possible to on ty override recency or to only over- . 
ride volume; both recency and volume limits may be 
overridden. 

[0071] Recency of contact can be managed by the 
proximity of one strategy to another strategy. There is a 
table CAMPAIGN-CLASS-LIMITS that defines the min- 
imum proximity between two strategy classes. A cus- 
tomer should not participate in two strategies within this 
defined proximity. The CAMPAIGN-CLASS-LIMITS ta- 
ble is a matrix that relates two strategy classes together 
such that a time limit is defined between the running of 
two strategies. 

[0072] The volume limit controls the number of con- 
tacts with the customer. It is the maximum number of 
strategies that a customer may be selected to partici- 
pate in over a rolling twelve month period, and is set at 
a system level. By default, every strategy will count to- 
wards this limit, but it Is possible to define the strategy 
to not count towards the volume limit (eg. An information 
strategy may not count towards the volume limit). It 
should be noted that this is not a limit on the volume of 
contacts - a lead may be contacted many times within 
a strategy. It is a limit on the number of times a customer 
can be selected for different strategies. 
[0073] Each strategy may have two sets of two vol- 
ume limits applied to it. One set is for the primary chan- 
nel class, the other is for the cascade channel class. The 
first limit within each set Is a limit on the total number of 
leads that can be generated for the strategy across all 
iterations of the strategy while the second limit is a limit 
on the number of leads per iteration of the strategy. Both 
these limits are implemented as upper boundaries as 
an absolute number (not a relative number). It is not 
mandatory for a strategy to have these limits applied to 
it. All of these limits are defined at a strategy level. If a 
strategy does not have volume limits defined then it Is 
an unlimited strategy, rather than a strategy that over- 
rides limiting. It is not possible to override strategy limits, 
nor does it make sense to do so; the strategy may be 



defined as unlimited if this is the desired result. 
[0074] At the channel instance level it Is possible to 
define two limits. The first limit is the total number of 
leads that can be allocated to the channel instance at 

5 any one time across alt strategies while the second limit 
Is a limit on the number of leads that can be allocated 
to the channel instance in any one cycle of all strategies. 
These limits ensures that a channel instance does not 
get too many new leads at a time, and also that there 

10 are not too many leads allocated to a channel instance 
for follow up at any given time. Both these limits are im- 
plemented as upper boundaries as an absolute number 
(not a relative number). It is not mandatory for a channel 
instance to have these limits applied to it. The channel 

IS Instance limits are applied and managed at the channel 
instance level, but are inherited from the channel class 
when the channel Instance is defined. A strategy that Is 
unlimited shou Id not direct Its leads to channel instances 
that are limited. It Is not possible for a strategy to over- 
do ride channel instance limiting. 

[0075] Channel instance limits are only taken into 
consideratbn when generating and allocating new 
leads. If the action of a step is to assign the lead to a 
channel instance that has limiting applied to it, and the 

25 channel instance Is at full capacity, the lead will be suc- 
cessfully allocated to the new channel instance. This will 
mean that the channel instance is over capacity, and will 
probably not be able to cope with all the leads assigned 
to it (and certainty not any new ones). For this reason. 

30 consideration must be given to this situation when de- 
fining the channel instance limits to ensure that there Is 
in fact some spare capacity when the limits for the chan- 
nel instance have been reached. 
[0076] If the primary (intended) channel class for the 

35 allocation of leads is at full capacity, the Strategy Man- 
agement System supports a one level cascade to a sec- 
ondary channel class. If the secondary channel class is 
also at full capacity, then the only action Is to make the 
lead an unrealised opportunity. The secondary channel 

40 class must be nominated for the strategy, as the system 
will not make the decision itself. If no secondary channel 
class has been defined then the lead will become an 
unrealised opportunity. Cascading is supported for each 
iteration of a strategy. There is only one cascade chan- 

45 nel class per strategy. Cascading is only supported for 
the first step of each celt during the lead generation and 
allocation process, not at any subsequent steps. 
[0077] If a lead Is allocated to a channel instance with 
insufficient capacity to handle the lead, allocating it to 

50 another channel class may not be a desirable result. For 
example, If a newly generated lead is intended to go to 
the Personal Banker channel class but the Personal 
Banker channel instances are at full capacity. It may be 
more desirable to send the lead to the 

55 UNREALlSED_OPPORTUNITIES table rather than to 
overflow the lead to an alternate channel class. The 
UNREALlSED_OPPORTUNITIES table is available for 
analysis to determine what sort of opportunities are be- 
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ing missed. The analysis performed on this table may 
result in new strategies being targeted at customers that 
were limited out, changes in strategy strategy to ensure 
that the frequency and volume of contact Is kept to a 
level that minimises the likelihood of leads being unre- 
alised and an investment being made in the channel 
class to increase the capacity of the channel class (eg. 
extending the Call Center office space). 
[0078] Dynamic scoring is a process that takes place 
as part of the generation of leads. It Is essentially a proc- 
ess that is either too costly or complex to run for the 
whole customer base, but is important to run for a tar- 
geted subset of the customer base. The targeted subset 
is essentially all leads that are selected when the selec- 
tion method is executed. Once the customer limiting has 
been performed, and before either strategy or channel 
instance limiting, these models are run for the lead set. 
As a result of the nrKXjels being run. the lead set nnay be 
re-sorted, or new selection variables may be added to 
the lead. It is important that the original selection varia- 
bles are not overwritten. 

[0079] Within a strategy there are two types of com- 
munication from a lead that are treated specially. They 
are a request for more information and a complaint. 
These two responses are identifiable and are placed in 
separate tables to other responses, namely the COM- 
PLAINTS and MOREJNFO.REQUESTS tables. 
These tables both contain the lead identifier and the se- 
lection variables associated with the lead in the strategy 
so that analysis can be conducted on these response 
types. The analysis may find that there are particular 
strategies or channel instances for example that gener- 
ate more requests for information or complaints than 
others. The tables also provide the ability to act on the 
request for information or complaint. A fulfilment proc- 
ess may be implemented against the 
MORE_INFO_REQUESTS table, and a complaint man- 
agement system may use the COMPLAINTS table for 
input. 

[0080] Use of the database database relationship 
analysis and strategy implementation tool analysis, de- 
cisioning and implementation tool in a financial services 
environment allows the financial institution to apply the 
tool on a regular basis (eg every night) so that relevant 
events occuring among its customers may be detected 
by the Event Dectective System. A decision as to what 
strategy should be implemented in relation to those cus- 
tomers is made by the Strategy Management System 
and implementation instructions are given to the appro- 
priate channels. In other words, the database analysis, 
decision ing and implementation tool informs the finan- 
cial institution which of its customers is it important to 
take action in regard each day, the reason why action is 
necessary, the action to be taken and how it should be 
implemented. This ensures that the window of opportu- 
nity in relation to individual customers is captured and 
timely action is enabled. The database analysis, deci- 
sioning and implementation tool leverages the intimate 



customer data within the data warehouses of the finan- 
cial institution so enhancing its understanding of the re- 
quirements of its customers and identifying opportuni- 
ties or the necessity to take some other act iom in relation 

s to its customers. 

[0081] Although, the database relationship analysis 
and strategy implementation tool analysis implementa- 
tion tool has been described in relation to the environ- 
ment of a financial institution, the tool can be used in 

10 other environments. For example, in the retail sector, the 
tool may be integrated into the customer database en- 
vironment of large supermarket chains, department 
stores or airline companies so albwing such institutbns 
to detect relevant events in relation to their customers 

IS and to decide on and implement appropriate strategies 
on the basis of the detected events. The tool could also 
be used in a database environment which contains 
records relating to convicted or suspected criminals so 
as to detect events which noay be useful in solving crime. 

20 

Claims 

1. A method of contacting parties, characterized by 
2S the following steps: 

a) maintaining a vector management system, 
VMS; 

b) obtaining leads from the VMS which identify 
30 parties to be contacted; 

c) using the leads, making contact with parties; 
and 

d) imposing the following limits on the contacts: 

35 i) a maximum limit on the number of times 

each party is contacted during any given 
calendar period; and 

ii) a minimum delay between one contact, 
and the next contact, of each party. 

40 

2. Method according to claim 1 , further comprising the 
step of placing a limit on the number of leads used 
to contact the parties. 

45 3. A method of communicating with parties, character- 
ized by the following steps: 

a) maintaining a database in which multiple da- 
ta items are associated with each party; 
so b) selecting a data item, monitoring it over time 

and identifying changes which occur in it; 

c) listing the parties associated with the 
changed data item; 

d) dividing the listed parties into at least two 
55 groups; 

e) repeating steps (b) through (d) at least once, 
with respect to at least one other data item; 

f) contacting parties in the first group through a 
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first type of communication channel, subject to 
the following limits: 

i) no party is contacted more than a prede- 
termined number of times in any calendar 
period; and 

ii) after one contact of a given party, a sub- 
sequent contact is not made until a prede- 
termined interval has expired. 

4. Method according to claim 3. and further comprising 
the step of placing a limit on the number of contacts 
made through the first communication channel. 

5. Method according to claim 4, further comprising the 
step of placing a limit on the number of contacts 
made through the second channel. 

6. Method according to claim 5, further comprising the 
step of contacting some parties in the first group 
through the second channel. If the number of parties 
in the first group exceeds a limit. 

7. Method according to claim 3, further comprising the 
step of placing a limit on the number of parties In 
the first group who are contacted. 

8. A method of communicating with parties, compris- 
ing the following steps: 

a) maintaining a database In which 

I) a record is associated with each party, 
and 

Ii) the records contain some common data 
items; 

b) selecting a data item contained in multiple 
records; 

c) monitoring the records containing the select- 
ed data item; 

d) when changes occur In the selected data 
item, selecting a strategy from a group of strat- 
egies, said group of strategies including differ- 
ent communication tactics designed to influ- 
ence behaviour of the parties; 

e) listing the parties associated with the 
changed data item; 

f) dividing the listed parties Into at least two 
groups; 

g) repeating steps (b) through (f ) at least once, 
with respect to at least one other data item; 

h) contacting parties In the first group through 
a first type of communication channel, and con- 
tacting parties in the second group through a 
second type of communication channel; 

1) a maximum limit on the number of times 



each party Is contacted during a calendar 
period; and 

ii) a minimum delay between one contact, 
and the next contact, of each party. 

s 

9. Method according to claim 8, further comprising the 
step of contacting some parties in the first group 
through the second channel, if the number of parties 
in the first group exceeds a limit. 

10 

1 0. Method according to claim 8, further comprising the 
step of placing a limit on the number of parties in 
the first group who are contacted. 
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